System and method for electronic lead verification

ABSTRACT

A system and a method provide a lead verification service. A lead generator contacts a verification server when a visitor lands on a hosting site of the lead generator to enter lead information into a form. The verification server issues a reference key (token) to the lead generator and collects information about the visitor and the hosting site of the lead generator, using the reference key to identify the collected information. When the visitor submits the form, the lead generator sends the form data, which includes the entered lead information and the reference key received from the verification server, to at least one interested party. When the verification server receives a request for the collected information from the interested party, the collected information is retrieved based on the reference key included in the request and sent to the requesting interested party.

CROSS-REFERENCE TO RELATED APPLICATION AND PRIORITY CLAIM

This application claims priority under 35 U.S.C. § 120 as a continuationof U.S. patent application Ser. No. 16/795,378 filed on Feb. 19, 2020,which claims priority under 35 U.S.C. § 120 as a divisional of U.S.patent application Ser. No. 13/106,641 filed on May 12, 2011 (now U.S.Pat. No. 10,614,417). These applications are hereby incorporated byreference in their entirety.

TECHNICAL FIELD OF THE INVENTION

The present disclosure is directed, in general, to communicationsystems, and more specifically, to a system and method for verifying alead that was collected from a website.

BACKGROUND OF THE INVENTION

“Lead generation” generally refers to the creation or generation ofprospective consumer interest or inquiry into products or services of abusiness. There has been a recent trend towards lead generation usingthe Internet. In a typical lead generation scenario, a consumercompletes an online request form on a website. When the form iscompleted and submitted, the consumer's information may be sent to aparty interested in the data or alternatively evaluated to match theconsumer with one or more appropriate providers. Typically, the leadgeneration website is owned and operated by one party (the lead seller)while a separate party receives the data (the lead buyer).

Currently, there are no reliable means for a lead buyer to verify whenand where an Internet lead was collected by a lead seller. Since thelead seller hosts the web form, the buyer that purchases leads has nocontrol of the form used to collect the lead and therefore may not beable to verify where the lead was collected or if it was even collectedon a web form. The lead buyer is unable to verify basic informationabout the lead and is therefore unable to verify the authenticity of thelead. On what website was it collected? What information was presentedto the consumer on the web page? When was it collected? Was it submittedby a consumer from a web browser? What was the IP address of theconsumer submitting the lead? To answer these questions the buyer mustrely on the word of the seller with no way to independently verify.Because of this basic lack of transparency it is easy for a lead sellerto take advantage of a lead buyer by misrepresenting when, where and howleads were collected. For example, a lead seller may represent that thelead was collected on one site when it was in fact collected on another.

As such, there is a need for an improved means for independentlyverifying the authenticity of leads that are generated from leadgenerating websites.

SUMMARY OF THE INVENTION

According to one aspect of the present invention, a method of providinga verification token (aka certificate of authenticity) with an internetlead is provided. A verification server is notified when a visitoraccesses a web page to enter information into a form. A reference keycomprising a unique identifier is received from the verification server.And in response to the visitor submitting the form, the form data issent to at least one interested party. The form data includes thereference key and the information entered by the visitor.

According to another aspect of the present invention, a method of averification server for supporting a lead verification service isprovided. A reference key that includes a unique identifier is generatedin response to receiving a notification from a lead generator on awebsite that is being accessed by a visitor. The reference key is sentto the lead generator. Information about the lead generator and thevisitor that is accessing the website is collected. The collectedinformation is associated with the reference key. The collectedinformation is sent to at least one interested party in response toreceiving a valid request comprising the reference key.

According to another aspect of the present invention, a system forsupporting a lead verification service is provided. The system includesa verification server and a web server that is hosting a websitecomprising a lead generator. The lead generator is configured to notifythe verification server when a visitor accesses the website to enterinformation into a form, receive a reference key comprising a uniqueidentifier from the verification server, and send the form data to atleast one interested party in response to the visitor submitting theform, the form data comprising the reference key and the informationentered by the visitor.

According to yet another embodiment of the present invention, anapparatus for supporting a lead verification service is provided. Theapparatus includes a communication interface, a memory, and a processor.The communication interface sends and receives information. The memorystores instructions for providing lead information that can be verified.And the processor performs the instructions stored in the memory togenerate a verification token that includes a unique identifier inresponse to receiving a notification from a lead generator on a websitethat is being accessed by a visitor, send the verification token to thelead generator, collect information about the lead generator and thevisitor that is communicating with the lead generator, and send thecollected information to an interested party, in response to receiving avalid request, based on the verification token.

In some embodiments, the system ensures that the information collectedand associated with a particular reference key is valid. When the leadgenerator communicates with the verification server, there are multipleinteractions between the systems (i.e. the verification server and thesystem on which an instance of the lead generator is being executed) tohelp ensure that the information collected is accurate and the leadgenerator is not trying to misrepresent that information.

Before undertaking the DETAILED DESCRIPTION OF THE INVENTION below, itmay be advantageous to set forth definitions of certain words andphrases used throughout this patent document: the terms “include” and“comprise,” as well as derivatives thereof, mean inclusion withoutlimitation; the term “or,” is inclusive, meaning and/or; the phrases“associated with” and “associated therewith,” as well as derivativesthereof, may mean to include, be included within, interconnect with,contain, be contained within, connect to or with, couple to or with, becommunicable with, cooperate with, interleave, juxtapose, be proximateto, be bound to or with, have, have a property of, or the like; and theterm “controller” means any device, system or part thereof that controlsat least one operation, such a device may be implemented in hardware,firmware or software, or some combination of at least two of the same.It should be noted that the functionality associated with any particularcontroller may be centralized or distributed, whether locally orremotely. Definitions for certain words and phrases are providedthroughout this patent document, those of ordinary skill in the artshould understand that in many, if not most instances, such definitionsapply to prior, as well as future uses of such defined words andphrases.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present disclosure and itsadvantages, reference is now made to the following description taken inconjunction with the accompanying drawings, in which like referencenumerals represent like parts:

FIG. 1 illustrates a simplified block diagram of a communication systemmay be utilized according to an embodiment of the present disclosure;

FIG. 2 illustrates the interactions among components in a communicationsystem for verifying a lead according to an embodiment of the presentdisclosure;

FIG. 3 illustrates a process in a lead generator for providing a leadthat can be verified according to an embodiment of the presentdisclosure;

FIG. 4 illustrates a process in a verification server for supporting thelead verification service according to an embodiment of the presentdisclosure;

FIG. 5 illustrates an example of monitoring a web page that hosts thelead generator according to an embodiment of the present disclosure; and

FIG. 6 illustrates a system suitable for implementing one or moreembodiments of the present disclosure.

DETAILED DESCRIPTION OF THE INVENTION

FIGS. 1 through 6 , discussed below, and the various embodiments used todescribe the principles of the present disclosure in this patentdocument are by way of illustration only and should not be construed inany way to limit the scope of the disclosure. Those skilled in the artwill understand that the principles of the present disclosure may beimplemented in any suitably arranged system. This invention may,however, be embodied in many different forms and should not be construedas limited to the embodiments set forth herein. Rather, the disclosedembodiments are provided such that this disclosure will be thorough andcomplete, and will fully convey the scope of the invention to thoseskilled in the art. The principles and features of this invention may beemployed in varied and numerous embodiments without departing from thescope of the invention.

Furthermore, well known or widely used techniques, elements, structures,and processes may not be described or illustrated in detail to avoidobscuring the disclosure. Although the drawings represent embodiments ofthe disclosure, the drawings are not necessarily to scale and certainfeatures may be exaggerated or omitted in order to better illustrate andexplain the present invention.

Embodiments of the present disclosure assume that lead sellers will wantto provide a certificate of authenticity with every lead. Doing so lendscredibility as they are willing to have their leads independentlyverified by a third party. Embodiments of the present disclosure alsoassume that an unscrupulous lead vendor would want to trick averification server into misreporting the URL of a page where a lead wascollected. Without proper means of authentication these unscrupulouslead vendors would be free to misrepresent an Internet lead whilemaintaining the appearance of being a trustworthy vendor. Embodiments ofthe present disclosure take a passive approach to solving this problemby quietly monitoring attempts to circumvent the verification process.The verification server does not expose to the lead vendor which checksare being performed when generating a reference key (e.g. verificationtoken) that can later be used by a lead buyer to verify the authenticityof the lead information. Instead, each reference key is used to registera list of “suspicions” that are internally monitored for malfeasance.Suspicions can be used to register a level of confidence that theinformation collected and associated with a reference key waslegitimately generated.

FIG. 1 is a simplified block diagram illustrative of a communicationsystem 100 that may be utilized by various embodiments of thedisclosure. The communication system 100 includes a visitor 110, a leadgenerator (e.g. lead seller) 120, a verification server (also referredto as a “trust form server”) 130, and at least one lead buyer 140. Thecommunication system 100 may be utilized to facilitate communicationbetween the described elements 110-140 through a private communicationnetwork (such as a local area network (LAN)) or a public communicationnetwork such as the Internet in order to allow verification of a leadprovided by the lead generator 120. In other configurations, thecommunication system 100 may utilize any other suitable communicationtechnology.

As used herein, each of the elements 110-140 may generally refer to anyobject, device, server, software, web page, or any combination of thepreceding that is generally operable to communicate with anotherelement. The elements 110-140 may also represent a user profilerepresenting a person. The user profile may comprise, for example, anaddress for the user, a user name, a pass code, other user information,or any combination of the preceding. Additionally, the elements 110-140may represent a device that comprises any hardware, software, firmware,or combination thereof operable to communicate through the communicationsystem 100.

The visitor 110 may be a user (e.g. a consumer) or a computing device(e.g. a personal computer, a laptop, a mobile device, and such)controlled by the user to communicate with the lead generator 120 andsubmit contact information (e.g. lead data).

The lead generator 120 may be a website, a software program, a service,a form or script embedded onto a web page, or a web server that hosts aweb page through which the visitor 110 may submit lead data. Lead datamay include, but is not limited to, contact information of a person orentity, the type of product or service that the person or entity isinterested in purchasing, information related to pre-qualification to apurchase, purchase preferences, and any other information that maygenerally be gathered concerning the visitor 110. The lead generator 120may also refer to the hosting page that hosts a script for supportingthe lead verification service. When the visitor accesses the web pagethat hosts the lead generator 120, the lead generator 120 may beexecuted in the visitor's browser.

According to certain configurations, the lead generator 120 may embed ascript onto a web page that contains a form (e.g. hosting page) forsubmitting lead information. The script may also be placed on any webpage (including those that don't contain the form). The script may bewritten in any appropriate language (e.g. Perl, JavaScript, Ruby,Python, and such) and installed by the publisher of the hosting page orform. When the visitor 110 establishes a connection with the leadgenerator 120, the lead generator 120 notifies the verification server130. According to an embodiment, a series of scripts may be loaded by avisitor's browser from the verification server, the verification servergenerates a certificate for every visit to a page. According to anembodiment, the notification may comprise a request for a reference keythat can be used to verify the lead information submitted by the visitor110. Upon receiving the reference key from the verification server 130,the lead generator 120 associates the lead information submitted by thevisitor 110 with the reference key and sends the reference key alongwith the lead information to at least one lead buyer 140.

In certain configurations, the lead generator 120 may determine theappropriate lead buyer 140 based on the lead information. For example,any one or more of the contact information, qualification attributes,type of product or service requested, and such, may be used to determineto which lead buyers 140 the lead information should be sent. Inaddition, the appropriate lead buyer(s) 140 may be selected based on anyadditional scheme. For example, the lead buyers may be notified of thenewly submitted lead information and be given the opportunity topurchase the lead information. In other configurations, the leadgenerator 120 may simply send lead information to a pre-programmeddestination. Furthermore, although FIG. 1 shows a direct communicationbetween the lead generator 120 and the leader buyer 140, in certainconfigurations, there may be intermediate elements between the two.

The verification server 130 performs operations related to storinginformation that may be used to verify the lead data collected by thelead generator 120. In particular configurations, the verificationserver 130 collects information about the visitor 110 and the leadgenerator 120 during the communication session during which the leadgenerator 120 receives contact information and other relevantinformation (i.e. lead data) submitted by the visitor 110.

The information collected by the verification server 130 may include,but is not limited to, the Uniform Resource Locator (URL) of the hostingpage (where the script is located) and/or the form where the lead datais being collected, Hypertext Transfer Protocol (HTTP) headers for theweb page (e.g. for the lead generator or User-Agent) from the visitor110's browser, date and time that the visitor arrived at the hostingpage or submitted the lead data, and the internet protocol (IP) addressof the visitor 110. Additionally, in particular configurations, theverification server 130 may capture a screenshot of the hosting page orthe form being submitted by the visitor 110 and/or text associated witha form that may be populated by a visitor accessing a website for theform. For example, in particular configurations, the text may beassociated with terms or conditions corresponding to a form. Thecollected information may be stored in a certificate that can later beretrieved by at least one lead buyer 140 to verify the authenticity orvalidity of the corresponding lead data purchased or acquired from thelead generator 120.

In particular configurations, the verification server 130 may be acomputer system that communicates with the lead generator 120 and atleast one lead buyer 140. When contacted by the lead generator 120, theverification server 130 generates the reference key (e.g. a token) andsends the reference key to the lead generator 120. The reference key maybe included in a token and comprise a string of unique alphanumericcharacters that becomes associated with the certificate (i.e.information collected by the verification server 130) and the lead datacollected by the lead generator 120. This information together (leaddata and reference key) may be communicated to a lead buyer 140.

When the lead buyer 140 sends a request for the certificate along withthe reference key, the verification server 130 sends informationcorresponding to the certificate or the certificate, itself, to the leadbuyer 140.

In particular configurations, the lead buyer 140 may be aproduct/service vendor, computer, or an online account that representsthe vendor. According to an embodiment, the verification server 130 mayonly provide information corresponding to the certificate or thecertificate, itself, to a lead buyer that subscribes to the verificationservice. In this configuration, the lead buyer 140 must be a subscriberof the verification service in order to receive the certificates fromthe verification server 130. The certificate will include theinformation collected by the verification server 130 about the visitor110 and the hosting page of the lead generator 120 during the submissionof the lead data. According to the embodiment, the certificate mayinclude one or more of the information described in Table 1.

TABLE 1 INFORMATION DESCRIPTION Page URL where the lead was collected,and the URLs of any containing pages, in the event that inline frames(IFrames) are employed on the hosting page HTTP Headers from the browserof visitor 110, regarding the lead generator Date & Time when thevisitor 110 arrived at the hosting page to submit the lead informationIP address of the visitor 110 Form information Any informationassociated with a form filled out by a visitor, including the formdisplayed and the text associated with the form

In particular configurations, data may be collected by the verificationserver 130 and not sent to the lead buyer 140. Rather, a subset ofinformation may be sent.

According to certain configurations, the verification server 130 mayignore or actively avoid collecting any personally identifiableinformation about the visitor 110 in order to maintain privacy andintegrity. Any personal information that may have been inadvertentlycollected may not be included in the certificate data that is sent tothe requesting lead buyer 140. For example, when capturing the page URLwhere the lead is collected, it is possible that additional data iscaptured as additional parameters appended to the page URL. As the dataappended to the page URL is at the discretion of the publisher of thehosting page, personal information that is appended to the URL (e.g.name of the lead or traffic data) may inadvertently be collected by theverification server 130, which captures the complete URL. According toan embodiment, the verification server 130 may hide or remove thepersonal information that is appended to the captured URL of the hostingpage for the lead generator 120.

Because the script installed on the lead generator 120 only causes theverification server to be notified and to include the reference key(i.e. token) into the lead form, changes regarding the type ofverification information that is collected to authenticate the leadgenerator 120 only need to be implemented by the verification server130. This allows the verification server to be flexible in modifying orenhancing verification techniques as lead vendors become savvier andHTML code becomes more advanced. As such, the entire process can beeasily altered without requiring intervention or allowing interferencefrom lead vendors. Put another way, the authentication process can bechanged at any time without any coordination with the lead vendors whohave chosen to implement the script.

FIG. 2 illustrates the interactions in a communication system forverifying a lead according to an embodiment of the disclosure. In block210, the lead generator 120 detects that a visitor (e.g. visitor 110)has accessed the hosting page for submitting lead information. When thevisitor accesses the host page of the form, the lead generator 120(which is being executed in the visitor's browser) executes a scriptthat was embedded in the form by the lead vendor to send a reference keyrequest 220 to the verification server 130. The reference key request220 may include information about the user-agent of the visitor browser,the visitor's IP address, a timestamp, and the URL of the form. In otherconfigurations, the reference key request 220 may occur at any suitabletime. In certain configurations, notifying the verification server 130may constitute a request for a reference key.

Upon receiving the reference key request 220, the verification server130 issues the reference key 230 to the lead generator 120. Theverification server 130 may also begin to collect information about thevisitor and/or the lead generator 120 in block 240. The collectedinformation becomes associated with the reference key 230. As discussedabove, in certain configurations, the collected information and thereference key 230 is stored as a certificate that can be identified bythe reference key 230 on the verification server 130. In certainconfigurations, the verification server 130 may begin collecting theinformation in block 240 upon receiving the reference key request 220and concurrently with or prior to issuing the reference key 230.

According to an embodiment, issuing the reference key 230 may comprise atwo-step process to ensure that the scripts loaded from the verificationserver 130 are not altered. In a first step of the embodiment, the leadverification server 130 captures the relevant data from the referencekey request 220 (e.g. information about the user-agent of the visitorbrowser, the visitor's IP address, a timestamp, and the URL of the form)as described with reference to block 240, stores the captured data intoa document (e.g. certificate) and sends a script download token tovisitor's browser that is executing the lead generator 120. The scriptdownload token (e.g. reference key) is embedded in a first script whichis returned to and executed in the visitor's browser. The purpose of thefirst script returned to the visitor's browser in the first step is torequest a second script which will insert the URL of the correspondingdocument stored in the verification server 130 into the form of the leadgenerator 120. The request for the second script contains the URL of thebrowser's document location and the “script download token” generatedduring the first step. If the lead generator 120 or a lead vendor triesto skip the first step, then the verification server 130 will record asuspicion in the document generated during the first. Suspicions willalso be recorded if the IP addresses or user-agents of the first andsecond steps do not match, or if the script download token has alreadybeen used or cannot be found. In an embodiment, the script downloadtoken may self-destruct or be rendered useless after a predeterminedtime period (e.g. 120 seconds), thereby preventing a lead vendor fromgenerating them in bulk for later use. In some embodiments multipleprocesses may also be used on consecutive requests as a way to confuseunscrupulous vendors. In this way, the verification server 130 mayensure that the scripts are being loaded directly from the verificationserver 130, thereby thwarting an unscrupulous vendor that may trydownloading the script, altering it, and then inserting the alteredscript into the lead generator 120 being run in the visitor's browser.This would also prevent the vendor from issuing reference keys or otherfalse URLs of the verification certificate.

According to some embodiments, the verification server 130 may want toensure that the scripts are being performed in the visitor's browser. Byincluding a script that must be successfully executed, the verificationserver 130 may ensure that the script is being executed in anappropriate script interpreter, rather than just parsed as a string forpertinent information. For example, the verification server 130 mayperform a calculation during the first step and ask the browser toperform the same calculation. The verification server 130 would checkthe visitor browser's calculation during the second step. If thecalculations do not match, then a suspicion would be registered in thecorresponding certificate. Obfuscation of the script code returned tothe visitor's browser can be used to prevent simple parsing by the leadvendor's code. This would be most effective if the obfuscationtechniques are rotated in random ways, making it difficult for the leadvendor's server-side code to fetch information out of the script withoutactually evaluating it in a script engine.

The verification server 130 may also count the number of certificatesgenerated by requests from the same IP address. If a high number ofcertificates are being generated by the same IP address, then asuspicion would be recorded with the corresponding certificates. Inanother embodiment, certain script calls to a document object model inthe hosting page can be used to ensure that the script interpreterexecuting the code is being run in a browser rather than in astand-alone interpreter like Rhino or V8.

In particular configurations, the verification server 130 may alsocontinue to monitor the hosting page of the lead generator 120 overtime, thereafter. As mentioned previously, reference key 230 may beincluded in a token and comprise a string of unique alphanumericcharacters. The verification server 130 may generate or assign thereference key 230.

In block 250, the lead generator 120 associates the received referencekey 230 with the form that is being populated by the visitor forsubmission of lead information. According to certain configurations, thereference key 230 may be stored in a hidden field of the form. In thehidden field, the reference key 230 may also be included in acertificate URL that can be used to access the stored certificate on theverification server 130.

In block 260, the lead generator 120 detects that the visitor hascompleted the form and submitted the lead information. The leadgenerator 120 then sends the submitted form data 270 to at least onelead buyer 140 or alternatively to an intermediate element that may, inturn, submit the data to the lead buyer 140. The submitted form data 270includes the lead information and the reference key 230.

The lead buyer 140 may then send a certificate request 280 to theverification server 130 to verify, among other things, the authenticityof the lead information that was included in the received form data 270.According to an embodiment, the lead buyer 140 may include the referencekey 230 in the certificate request 280. Alternatively, if thecertificate URL is included in the form data 270, the lead buyer 140 mayattempt to access the certificate URL, which may be constituted as thecertificate request 280.

Upon receiving the certificate request 280 (which includes the referencekey 230), the verification server 130 may retrieve the storedcertificate based on the reference key 230 and send the certificate data290 to the lead buyer 140. In an embodiment, the verification server 130may first determine whether the lead buyer 140 is a valid subscriber tothe verification service before sending the certificate data 290.

FIG. 3 illustrates a process 300 in a lead generator for providing alead that can be verified according to an embodiment of the presentdisclosure. The lead generator may be any web page, form, or script on ahosting page where a visitor may submit their lead information, such aslead generator 120.

In block 310, the lead generator detects that a visitor has landed onthe hosting page that contains the form for submitting lead information.In block 320, the lead generator sends a request for a reference key toa verification server (e.g. the verification server 130). In certainconfigurations, the lead generator simply notifies the verificationserver that a visitor has landed on the hosting page.

In block 330, the reference key is received and assigned to the instanceof the form that the visitor is using to submit the lead information.According to certain configurations, the reference key is stored in ahidden field on the form and may be included in a certificate URL.

In block 340, the lead generator determines whether the form has beensubmitted. If the form is not submitted, the process 300 ends. Accordingto an embodiment, the lead generator may determine that the form is notsubmitted if the form is not submitted within a specified period, theweb browser is closed before the visitor submits the lead information,or the visitor navigates away from the hosting page without submittingthe lead information.

In contrast, if the form is submitted, the lead generator sends the leaddata to at least one lead buyer in block 360 (or alternatively to anintermediate element that is in communication with the lead buyer) andends the process. According to certain configurations, the leadgenerator may determine to which lead buyer(s) the lead information isto be sent based on at least a portion of the lead information in thesubmitted form.

FIG. 4 illustrates a process 400 in a verification server for supportingthe lead verification service according to an embodiment of the presentdisclosure. The verification server (e.g. the verification server 130)may be a computer system that communicates with at least one leadgenerator (e.g. the lead generator 120) and at least one lead buyer(e.g. the lead buyer 140).

In block 410, the verification server receives a request for a referencekey from a lead generator. As described earlier, the request may simplybe a notification that a visitor has landed on a hosting page of thelead generator. In block 420, a reference key is generated and sent tothe requesting lead generator. In an embodiment, the verification servermay generate a token that serves as the reference key and send the tokento the lead generator.

In block 430, the verification server begins to collect informationabout the visitor the hosting page of the lead generator that requestedthe reference key. The information collected by the verification servermay include, but is not limited to, the Uniform Resource Locator (URL)of the hosting page or form where the lead data is being collected,Hypertext Transfer Protocol (HTTP) headers for the web page (e.g. forthe lead generator or User-Agent) from the visitor's browser, date andtime that the visitor arrived at the hosting page or submitted the leaddata, and the internet protocol (IP) address of the visitor.Additionally, the verification server may capture a screenshot of thehosting page or the form being submitted by the visitor and/or textassociated with a form that may be populated by the visitor accessing awebsite for the form. For example, in particular configurations, thetext may be associated with terms or conditions corresponding to a form.The collected information may be stored in a certificate or some otherdata structure that can be identified by the reference key. In certainconfigurations, the verification server may continue to monitor thehosting page of the lead generator over time and, as appropriate,provide such monitored information to a lead buyer. Additionally,according to certain configurations, the verification server may takeaffirmative steps to not collect any personally identifiable informationabout the visitor or traffic data and/or may remove such personallyidentifiable information.

In block 440, a request for certificate data is received. The requestmay be transmitted from a lead buyer that purchased or acquired leadinformation that included the reference key.

In block 450, the certificate data that corresponds to the reference keyincluded in the request is transmitted to the lead buyer that sent therequest. That is, the verification server determines the reference keyfrom the request for certificate data, retrieves the correspondingcertificate data (or data structure) based on the reference key, andsends the retrieved certificate data to the lead buyer. In particularconfigurations, monitored information may additionally be communicatedto the lead buyer.

According to certain configurations, the verification server may firstdetermine whether the lead buyer is a subscriber of the verificationservice or has appropriate access to the certificate data before sendingthe certificate data. For example, the verification server may request apassword, or the request for certificate data may include authenticationinformation that identifies the lead buyer. If the requesting lead buyerdoes not have access, the verification server may not send the requestedcertificate data.

According to certain configurations, as alluded to above, theverification server may also check the certificate data to ensure thatpersonal information of the visitor or traffic information that revealsthe referrer of the lead generator is not sent with the certificatedata.

FIG. 5 illustrates an example of monitoring a web page that hosts thelead generator according to an embodiment of the present disclosure. Webpage 610 is hosted on a lead vendor's server. The web page 610 containsa form 614 and a script 618 that has been added by the lead vendor. Whenexecuted by a visitor's browser, the script 618 on the web page 610(e.g. lead generator 120) communicates with the verification server 130.In a request for a reference key, the script 618 provides to theverification server 130 the URL 620 of the web page 610 where the form614 resides. At this point, the verification server 130 is “aware” ofthe URL of the form 614 and begins to monitor the web page 610 for anychanges. The changes to the web page 610 may be presented in an eventtimeline as shown in sample snapshots 630-650. The first snapshot 630 ofthe web page 610 may be taken when the verification server firstreceives a notification (or reference key request) from the script 618.From there on, the verification server 130 monitors the web page 610.The second and third snapshots 640 and 650 are taken when the changesare detected by the verification server 130. According to an embodiment,for each change detected, snapshots of the web page 610 are capturedincluding at least one of the HTML, image files, and a high-resolution,full-length image of the web page 610.

FIG. 6 illustrates a system suitable for implementing one or moreembodiments of the present disclosure. System 500 may be used inconnection with other embodiments of the disclosure to carry out any ofthe above-referenced functions and/or serve as a computing device forperforming the functions of the lead generator 120 and/or theverification server 130 of FIG. 1 . The computer system 500 includes aprocessor 502 (which may be referred to as a central processor unit orCPU) that is in communication with memory devices including secondarystorage 508, read only memory (ROM) 510, random access memory (RAM) 512,input/output (I/O) device 506, and network connectivity devices 504. Theprocessor 502 may be implemented as one or more CPU chips.

The secondary storage 508 typically includes one or more disk drives ortape drives and is used for non-volatile storage of data and as anover-flow data storage device if RAM 512 is not large enough to hold allworking data. Secondary storage 508 may be used to store programs thatare loaded into RAM 512 when such programs are selected for execution.Secondary storage devices 508 may include a variety of types of storagemedia such as, for example, floppy disk drives, hard disk drives, CD ROMdrives, DVD ROM drives, magnetic tape drives, solid state devices, orother suitable storage media. Although this embodiment employs aplurality of disk drives 508, a single disk drive 508 may be usedwithout departing from the scope of the disclosure. The ROM 510 is usedto store instructions and perhaps data that are read during programexecution. ROM 510 is a non-volatile memory device that typically has asmall memory capacity relative to the larger memory capacity ofsecondary storage. The RAM 512 is used to store volatile data andperhaps to store instructions. Access to both ROM 510 and RAM 512 istypically faster than to secondary storage 508.

I/O devices 506 may include printers, video monitors, liquid crystaldisplays (LCDs), touch screen displays, keyboards, keypads, switches,dials, mice, track balls, voice recognizers, card readers, paper tapereaders, or other well-known input devices. The network connectivitydevices 504 may take the form of modems, modem banks, Ethernet cards,universal serial bus (USB) interface cards, serial interfaces, tokenring cards, fiber distributed data interface (FDDI) cards, wirelesslocal area network (WLAN) cards, radio transceiver cards such as codedivision multiple access (CDMA) and/or global system for mobilecommunications (GSM) radio transceiver cards, and other well-knownnetwork devices. The network devices 504 may be connected to a computernetwork or a variety of other communicative platforms including, but notlimited to, a public or private data network; a local area network(LAN); a metropolitan area network (MAN); a wide area network (WAN); awire line or wireless network; a local, regional, or globalcommunication network; an optical network; a satellite network; anenterprise intranet; other suitable communication links; or anycombination of the preceding. These network connectivity devices 504 mayenable the processor 502 to communicate with an Internet or one or moreintranets. With such a network connection, it is contemplated that theprocessor 502 might receive information from the network, or mightoutput information to the network in the course of performing theabove-described method steps. Such information, which is oftenrepresented as a sequence of instructions to be executed using processor502, may be received from and outputted to the network, for example, inthe form of a computer data signal embodied in a carrier wave.

Such information, which may include data or instructions to be executedusing processor 502 for example, may be received from and outputted tothe network, for example, in the form of a computer data baseband signalor signal embodied in a carrier wave. The baseband signal or signalembodied in the carrier wave generated by the network connectivitydevices 504 may propagate in or on the surface of electrical conductors,in coaxial cables, in waveguides, in optical media, for example opticalfiber, or in the air or free space. The information contained in thebaseband signal or signal embedded in the carrier wave may be orderedaccording to different sequences, as may be desirable for eitherprocessing or generating the information or transmitting or receivingthe information. The baseband signal or signal embedded in the carrierwave, or other types of signals currently used or hereafter developed,referred to herein as the transmission medium, may be generatedaccording to several methods well known to one skilled in the art.

The processor 502 executes instructions, codes, computer programs,scripts, as such, for performing the processes discussed in the presentdisclosure. The instructions, codes, computer programs, or scripts maybe accesses from hard disk, floppy disk, optical disk (these variousdisk based systems may all be considered secondary storage 508), ROM510, RAM 512, or the network connectivity devices 504.

Although FIG. 6 provides one embodiment of a computer system that may beutilized with other embodiments of the disclosure, such otherembodiments may additionally utilize computers other than generalpurpose computers as well as general purpose computers withoutconventional operating systems. Additionally, embodiments of thedisclosure may also employ multiple computer systems 500 or othercomputers networked together in a computer network. Most commonly,multiple general purpose computers 500 or other computers may benetworked through the Internet and/or in a client server network.Embodiments of the disclosure may also be used with a combination ofseparate computer networks each linked together by a private or a publicnetwork.

Several embodiments of the disclosure may include logic contained withina non-transitory storage medium. In the embodiment of FIG. 6 , the logicincludes computer software executable on the system 500. The medium mayinclude the RAM 512, the ROM 510, the disk drives 508, or other mediums.In other embodiments, the logic may be contained within hardwareconfiguration or a combination of software and hardware configurations.

The logic may also be embedded within any other suitable medium withoutdeparting from the scope of the disclosure.

It will be understood that well known processes have not been describedin detail and have been omitted for brevity. Although specific steps,structures and materials may have been described, the present disclosuremay not be limited to these specifics, and others may be substituted asit is well understood by those skilled in the art, and various steps maynot necessarily be performed in the sequences shown.

While several embodiments have been provided in the present disclosure,it should be understood that the disclosed systems and methods might beembodied in many other specific forms without departing from the spiritor scope of the present disclosure. The present examples are to beconsidered as illustrative and not restrictive, and the intention is notto be limited to the details given herein. For example, the variouselements or components may be combined or integrated in another systemor certain features may be omitted, or not implemented.

Also, techniques, systems, subsystems and methods described andillustrated in the various embodiments as discrete or separate may becombined or integrated with other systems, modules, techniques, ormethods without departing from the scope of the present disclosure.Other products shown or discussed as directly coupled or communicatingwith each other may be coupled through some interface or device, suchthat the products may no longer be considered directly coupled to eachother but may still be indirectly coupled and in communication, whetherelectrically, mechanically, or otherwise with one another. Otherexamples of changes, substitutions, and alterations are ascertainable byone skilled in the art and could be made without departing from thespirit and scope disclosed herein.

What is claimed is:
 1. A method comprising: receiving a first request ata verification server, the first request associated with a visitoraccessing a web page comprising a form into which the visitor is able toenter information using a web browser of the visitor; in response to thefirst request, providing a reference key comprising a unique identifierfrom the verification server; collecting, at the verification server,information about the web page or form and about the visitor or the webbrowser of the visitor; generating a certificate containing thecollected information and associated with the reference key at theverification server, the certificate identified using a uniform resourcelocator (URL); and transmitting the certificate from the verificationserver.
 2. The method of claim 1, wherein the certificate lackspersonally identifiable information about the visitor.
 3. The method ofclaim 1, wherein the certificate comprises one or more of: a URLassociated with the web page or form; a Hypertext Transfer Protocol(HTTP) header for the web page; a timestamp associated with the webbrowser of the visitor accessing the web page; a network addressassociated with the web browser of the visitor; or text associated withthe form that the visitor populates.
 4. The method of claim 1, whereinthe certificate comprises a screenshot of at least one of the web pageor the form, the screenshot including at least a portion of theinformation entered by the visitor.
 5. The method of claim 1, whereinproviding the reference key comprises: providing a script to the webbrowser of the visitor; receiving a second request for a verificationURL according to the script; and providing the verification URL inresponse to the second request.
 6. The method of claim 1, whereinreceiving the first request comprises receiving the first request from alead verification service script executed by the web browser of thevisitor.
 7. The method of claim 1, further comprising: providingverification data from the verification server; and receiving additionaldata that is generated based on the verification data.
 8. The method ofclaim 1, further comprising: receiving a second request containing theURL; wherein transmitting the certificate comprises transmitting thecertificate in response to the second request.
 9. An apparatuscomprising: at least one memory configured to store instructions; and atleast one processing device configured to execute the instructionsstored in the at least one memory, the instructions when executedconfigured to cause the at least one processing device to: receive afirst request associated with a visitor accessing a web page comprisinga form into which the visitor is able to enter information using a webbrowser of the visitor; in response to the first request, provide areference key comprising a unique identifier; collect information aboutthe web page or form and about the visitor or the web browser of thevisitor; generate a certificate containing the collected information andassociated with the reference key, the certificate identified using auniform resource locator (URL); and initiate transmission of thecertificate.
 10. The apparatus of claim 9, wherein the certificate lackspersonally identifiable information about the visitor.
 11. The apparatusof claim 9, wherein the certificate comprises one or more of: a URLassociated with the web page or form; a Hypertext Transfer Protocol(HTTP) header for the web page; a timestamp associated with the webbrowser of the visitor accessing the web page; a network addressassociated with the web browser of the visitor; or text associated withthe form that the visitor populates.
 12. The apparatus of claim 9,wherein the certificate comprises a screenshot of at least one of theweb page or the form, the screenshot including at least a portion of theinformation entered by the visitor.
 13. The apparatus of claim 9,wherein the instructions that when executed are configured to cause theat least one processing device to provide the reference key comprise:instructions that when executed are configured to cause the at least oneprocessing device to: provide a script to the web browser of thevisitor; receive a second request for a verification URL according tothe script; and provide the verification URL in response to the secondrequest.
 14. The apparatus of claim 9, wherein the instructions thatwhen executed are configured to cause the at least one processing deviceto receive the first request comprise: instructions that when executedare configured to cause the at least one processing device to receivethe first request from a lead verification service script executed bythe web browser of the visitor.
 15. The apparatus of claim 9, whereinthe instructions when executed are further configured to cause the atleast one processing device to: provide verification data; and receiveadditional data that is generated based on the verification data. 16.The apparatus of claim 9, wherein the instructions when executed arefurther configured to cause the at least one processing device toreceive a second request containing the URL; wherein the instructionsthat when executed are configured to cause the at least one processingdevice to initiate transmission of the certificate comprise:instructions that when executed are configured to cause the at least oneprocessing device to initiate transmission of the certificate inresponse to the second request.
 17. A non-transitory computer readablemedium embodying instructions that when executed cause at least oneprocessing device to: receive a first request associated with a visitoraccessing a web page comprising a form into which the visitor is able toenter information using a web browser of the visitor; in response to thefirst request, provide a reference key comprising a unique identifier;collect information about the web page or form and about the visitor orthe web browser of the visitor; generate a certificate containing thecollected information and associated with the reference key, thecertificate identified using a uniform resource locator (URL); andinitiate transmission of the certificate.
 18. The non-transitorycomputer readable medium of claim 17, wherein the certificate lackspersonally identifiable information about the visitor.
 19. Thenon-transitory computer readable medium of claim 17, wherein thecertificate comprises one or more of: a URL associated with the web pageor form; a Hypertext Transfer Protocol (HTTP) header for the web page; atimestamp associated with the web browser of the visitor accessing theweb page; a network address associated with the web browser of thevisitor; or text associated with the form that the visitor populates.20. The non-transitory computer readable medium of claim 17, wherein thecertificate comprises a screenshot of at least one of the web page orthe form, the screenshot including at least a portion of the informationentered by the visitor.
 21. The non-transitory computer readable mediumof claim 17, wherein the instructions that when executed cause the atleast one processing device to provide the reference key comprise:instructions that when executed cause the at least one processing deviceto: provide a script to the web browser of the visitor; receive a secondrequest for a verification URL according to the script; and provide theverification URL in response to the second request.
 22. Thenon-transitory computer readable medium of claim 17, wherein theinstructions that when executed cause the at least one processing deviceto receive the first request comprise: instructions that when executedcause the at least one processing device to receive the first requestfrom a lead verification service script executed by the web browser ofthe visitor.
 23. The non-transitory computer readable medium of claim17, further embodying instructions that when executed cause the at leastone processing device to: provide verification data; and receiveadditional data that is generated based on the verification data. 24.The non-transitory computer readable medium of claim 17, furtherembodying instructions that when executed cause the at least oneprocessing device to receive a second request containing the URL;wherein the instructions that when executed cause the at least oneprocessing device to initiate transmission of the certificate comprise:instructions that when executed cause the at least one processing deviceto initiate transmission of the certificate in response to the secondrequest.